AWS再入門ブログリレー2022 Amazon GuardDuty 編

弊社コンサルティング部による「AWS 再入門ブログリレー 2022」の 34 日目のエントリ「Amazon GuardDuty」です。

AWS再入門2022

#Amazon GuardDuty

#AWS

川原征大

2022.03.22

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

当エントリは弊社コンサルティング部による『AWS 再入門ブログリレー 2022』の34日目のエントリです。

このブログリレーの企画は、普段 AWS サービスについて最新のネタ・深い/細かいテーマを主に書き連ねてきたメンバーの手によって、今一度初心に返って、基本的な部分を見つめ直してみよう、解説してみようというコンセプトが含まれています。

AWS をこれから学ぼう！という方にとっては文字通りの入門記事として、またすでに AWS を活用されている方にとっても AWS サービスの再発見や 2022 年のサービスアップデートのキャッチアップの場となればと考えておりますので、ぜひ最後までお付合い頂ければ幸いです。

では、さっそくいってみましょう。今日のテーマは『 Amazon GuardDuty 』です。

Amazon GuardDuty とは

GuardDuty は セキュリティサービス です。その中でも検知を担当しています。検知の目的は「インシデント、もしくはセキュリティリスクのある状態や振る舞いを早期に発見して、アクションにつなげること」です。

– 引用: AWS 環境における脅威検知と対応 #AWS-39 | AWS Summit Online

上の画像は NIST のセキュリティ統制における 5つのカテゴリ(識別、防御、検知、対応、復旧) に AWSサービスをマッピングさせたものです。

その中にある検知サービスは以下のとおりです。

★ Amazon GuardDuty:
- 脅威検知サービス
- 証跡やネットワークログから不審なアクティビディを検知する
Amazon Inspector:
- アプリスキャンサービス
- EC2インスタンスや ECRイメージへの継続的な脆弱性スキャンを実施する
AWS Security Hub:
- セキュリティイベント集中管理、およびクラウドセキュリティポスチャー管理サービス
- [セキュリティイベント集中管理] 様々なセキュリティサービスで発生するイベントを集中管理する
- [クラウドセキュリティポスチャー管理] AWS上の構成を評価して潜在的なセキュリティリスクを発見する
Amazon Macie:
- 機密情報の検知サービス
- S3バケットをスキャンして機密情報を発見する

上に書いたとおり GuardDuty は「検知」の中でも「脅威検知」を担当するサービスです。 GuardDuty がやってくれることをもう少し詳しく説明します。

ログの継続的な分析

まず始めに 各種ログを継続的に分析 してくれます。ここでいうログはAPI実行ログやS3アクセスログ、ネットワークログなどです。特にユーザー側でこれらのログ基盤を整備したり、実際に分析を行う必要はありません。 GuardDuty(AWS) 側でマネージドに実施してくれます。

脅威の検知

そして 「悪意のあるアクティビティ」を検出 してくれます。例えば「認証情報が外部で利用された」、「EC2インスタンスで暗号化通貨マイニングが実行されている」などの検出です。マネジメントコンソール上で検出結果(Findings)を確認できます。もしくは Amazon EventBridge(イベントの連携サービス) を利用してアラート通知を飛ばすこともできます。 GuardDutyを起点にセキュリティアクションを始めます。

とりあえず有効化しよう

GuardDutyの有効化はすぐに完了します。まだ有効化していない方は、すぐにやっちゃいましょう。

GuardDutyのページにて [今すぐ始める] を選択します。

「GuardDuty がログ監視を行うためのサービスロール」の情報を確認して、 [GuardDuty の有効化] を選択します。

はい。これで終わりです。2クリックで有効化できました。

この手軽さが GuardDuty の良いところです。あとは GuardDuty による検出を通知するようにしておきましょう。以下メール通知の実装参考です。

GuardDutyからのイベント通知をちょっと見やすくして通知する | DevelopersIO

検出結果を理解しよう

ここまで話したとおり、GuardDutyを始めるのは簡単です。もちろんユーザー側でのチューニングは可能ですが、基本はデフォルトの状態でも、さほど問題にはなりません。

ではユーザーのすべき大事なことは何でしょうか？それは 「GuardDutyの検出結果を理解してアクションを起こすこと」 です。そのために、この章では GuardDuty 検出結果(Findings) の中身を説明します。

検出結果の形式 (GuardDuty finding format)

検出結果は JSONで表現されます。 GuardDuty finding format と呼ばれる形式で各種属性とその値を表現します。

ただ、この JSONを頑張って解読する必要はありません。マネジメントコンソールから検出結果の情報を「整理した形」で確認できます。 (また、後述の「Amazon Detective 連携」を使うことで、素早い調査を実施できます)

検出結果のタイプ (type)

一番大事な要素です。「 どのようなアクティビディが起きたか 」を表すための識別子です。 GuardDuty 検出結果を理解するときに、まず見る項目です。

GuardDutyが検知するタイプの一覧は以下ドキュメントにまとまっています。

Finding types - Amazon GuardDuty

識別子はリソース単位で大別されます。投稿時点では以下 4種類のタイプがあります。

EC2 結果タイプ … EC2インスタンスに関連するタイプです
IAM 結果タイプ … IAMリソースおよびアクセスキーに関連するタイプです
S3 結果タイプ … S3リソース(オブジェクト) に関連するタイプです ( アップデート 章で別途説明)
Kubernetes 結果タイプ … Amazon EKSクラスターに関連するタイプです ( アップデート 章で別途説明)

例えば、先程の画像の検出結果タイプは UnauthorizedAccess:EC2/SSHBruteForce でした。これは EC2 結果タイプです。該当するドキュメントの説明もこちらにあります。

全てを把握しておく必要は無いですが、リスクの高いものは事前に把握して、ドキュメントも読んでおくと良いでしょう。いざ GuardDuty で検知されたときに、対応をスムーズにするためです。

検出結果のその他属性

検出結果のタイプで「どのようなアクティビディが起きたか」を把握したら、次は他の属性を確認して、その詳細を補完していきます。

基本はマネジメントコンソールに整理した形で表示されているので、上から見ていくと良いです。

全ての属性の説明は割愛します。 リソースロール属性 は把握しておくと良いでしょう。

リソースロール

これはリソースの立ち位置(攻撃を受けているのか、攻撃を発信しているのかを表すものです。 リソースロール=TARGET の場合はこのリソースが不審なアクティビティのターゲット (TARGET) であることを表しています。 リソースロール=ACTOR の場合は、そのリソース自身が不審なアクティビティを行っている主体(ACTOR) であることを表しています。

「タイプ」および「リソース(リソースIDやリソースロール)」を確認して

どのようなアクティビディが起きているか
どのリソースが関与しているか
そのリソースが攻撃を受けている(TARGET) のか、攻撃を発信している (ACTOR) のか

を判断すると良いでしょう。

カスタマイズ、サービス連携

IPリスト

[設定 > リスト] にて 信頼されている IP リスト と 脅威リスト をカスタマイズできます

信頼されている IP リスト

「安全に通信できることが分かっている IPアドレス」のリストを登録します。このリストに登録されている IPアドレスからの検出結果は生成されなくなります。

脅威リスト

こちらには「既知の悪意のあるIPアドレス」のリストを登録します。このリストに登録されている IPアドレスのアクティビディを発見して、検出結果として生成します。

参考: 脅威リストを使ったGuardDutyの検出テスト | DevelopersIO

抑制ルール

検出結果一覧のページで抑制ルールを作成できます。抑制ルールは「フィルタの組み合わせ」として登録します。

「フィルタの組み合わせ」にマッチする検出結果は自動的にアーカイブされるようになります。

誤検知が頻出している検出結果があり、ノイズとなる場合に使いましょう。その際はフィルタを組み合わせて、「誤検知のみ除外」できていること意識します。本来検知してほしい検出結果がアーカイブされないように注意します。

通知

検出結果の内容次第では素早いセキュリティ対応が必要になることがあります。そのため通知の仕組みはほぼ必須です。作っておきましょう。

EventBridgeを使ってメールや Slack、監視ツールなどに通知する仕組みを作ります。

メール実装の参考: GuardDutyからのイベント通知をちょっと見やすくして通知する | DevelopersIO
Slack実装の参考: 新しくリリースされたAWS Chatbotを使ってGuardDutyのSlack通知をするといいよって話 | DevelopersIO

サービス連携

AWS Security Hub 連携

Security Hub は同じく検知のサービスです。主に以下 2つの主要機能を持ちます。

[セキュリティイベント集中管理] 様々なセキュリティサービスで発生するイベントを集中管理する
[クラウドセキュリティポスチャー管理] AWS上の構成を評価して潜在的なセキュリティリスクを発見する

この [セキュリティイベント集中管理] 機能が GuardDuty と関連があります。 GuardDuty の検出結果を Security Hub 側でも管理できます。これはデフォルトで設定されていて、特に追加設定は必要ありません。

また、最近のアップデートで Security Hub の「リージョン集約」が可能になりました。複数リージョンに散らばった GuardDutyのイベントも、 Security Hub 経由であれば集約リージョンにてまとめて確認できます。

参考: 【アップデート】AWS Security Hub が検出結果のリージョン集約に対応しました | DevelopersIO

Amazon Detective 連携

Amazon Detective はセキュリティ調査のサービスです。不審なアクティビディの原因を簡単に分析、調査、特定できます。特定に必要な各種関連するログの可視化も行ってくれます。

この Detective もデフォルトで GuardDuty と統合されています。 GuardDuty マネジメントコンソールから Detective の調査画面へすぐに遷移できます。

インシデント調査のスピードアップのためにも Detective は有効化しておくとよいでしょう。

参考: セキュリティインシデントの調査が捗るAmazon DetectiveがGAしたのでメリットとオススメの使い方を紹介します | DevelopersIO

マルチアカウント利用(AWS Organizations 連携)

GuardDuty はマルチアカウント利用ができます。

Amazon GuardDuty で複数のアカウントを管理する - Amazon GuardDuty

上図のように「管理アカウント(1つ)」と「メンバーアカウント(複数)」を構成します。管理アカウント上でメンバーアカウントの GuardDuty 検出結果を集中管理できます。

AWS Organizations 環境であれば、このマルチアカウント構成を簡単にセットアップできます。通常だと「管理アカウントからメンバーアカウントへ招待」および「メンバーアカウント側でそれを受諾」するプロセスがセットアップで必要です。 Organization連携を使うとそれを省くことができます。

便利な Organizations連携のセットアップについては以下ブログを参照ください。

Organizations 環境で Amazon GuardDuty を全リージョンへ簡単セットアップしてみる | DevelopersIO

アップデート

そのほかの比較的新しいアップデートをピックアップします。

S3保護

2020/07 に S3保護機能が実装されました。この機能を有効化すると、GuardDutyは S3のオブジェクトレベルのAPIをモニタリングします。 S3バケット内で起きた不審なオブジェクト操作を検知できます。

S3バケット・オブジェクトを完全にモニタリングするためにも、この機能はぜひ有効化しておきましょう。

参考: Amazon GuardDuty で S3 への不審なアクティビティを脅威検出できるようになりました！ | DevelopersIO

EKSクラスターへの脅威検知

2022/01 のアップデートで Amazon Elastic Kubernetes Service (Amazon EKS)クラスターへの脅威の検出をサポートしています。この機能を有効化すると、 GuardDutyは Amazon EKS の Audit Logs を取り込み、検出結果を生成するようになります。